This PR goes hand in hand with prebuild/node-gyp-build#4.

Very cool. Did you test that this works on windows?

not yet, will do

I don't see anything that wouldnt work but you never know ... windows

I tested this with taglib2 and it works :)

@juliangruber So in order to use this, you would land this patch and run https://github.com/juliangruber/prebuildify-load ?

@bcomnes That is outdated by now. We can instead add the missing functionality to node-gyp-build, provided that it doesn't need new dependencies.

Sounds good

Maybe a package rename is in order, but we can table that for now.

PR(s) welcome!

Don't quite have a vision of what you mean, maybe if we write it up?

To clarify, I thought it was okay to add functionality to the existing modules and that we could later choose to rename node-gyp-build to something more generic.

But on second thought, there's a fundamental difference between prebuildify-load and node-gyp-build that may in fact warrant the existence of prebuildify-load (which has a better name too). While node-gyp-build wraps node-gyp, prebuildify-load externalizes that. Compare:

"scripts": {
  "install": "node-gyp-build"
}

"scripts": {
  "install": "prebuildify-load || node-gyp build"
}

The latter approach avoids needing integration code specific to e.g. cmake-js.

If we can agree (@mafintosh @ralphtheninja) that this is the preferred approach, we could move prebuildify-load into the prebuild org and revive it, phasing out node-gyp-build.

node-gyp-build is the only production dep needed to run the prebuildify stack, so we need to keep that extremely light (all the install speed comes from that package having no deps), so adding cmake there is prob a nogo. Making a new package for that use-case is fine

@mafintosh My point was, with the approach of prebuildify-load, there's no need to add cmake.

I don’t personally have a need or a valid perspective on this so I’ll abstain

Old issue, but I think this makes sense actually. @vweevers should we revisit this?

It's a good feature and doesn't add complexity. I'm for it, as long as it's semver-major because it will break prebuildify-cross.

@vweevers i just registered the @prebuild org on npm (you should have gotten an invite). Then we could make a prebuild loader tool at @prebuild/load (i see julian's is archived)

we could revive mine as well, I'm open to hand anything over

@juliangruber Could you register your fork on npm so we can use it?

This fixes #49

@juliangruber Could you register your fork on npm so we can use it?

You can also publish it :) Or use the npm github syntax